There is currently a proliferation of organizational networked computing systems. Every type of organization, be it a commercial company, a university, a bank, a government agency or a hospital, heavily relies on one or more networks interconnecting multiple computing nodes. Failures of the networked computing system of an organization, or even of only a portion of it, might cause significant damage, up to completely shutting down all operations. Additionally, much of the data of the organization, if not all the data, exist somewhere on its networked computing system, including all confidential data comprising the “crown jewels” of the organization, such as prices, details of customers, purchase orders, employees' salaries, technical formulas, etc. Loss of such data or leaks of such data to unauthorized external entities might be disastrous for the organization.
Many organizational networks are connected to the Internet at least through one network node, and consequently may be subject to attacks by computer hackers or by hostile adversaries. Quite often the newspapers report incidents in which websites crashed, sensitive data was stolen, or service to customers was denied, where the failures were the results of hostile penetration into an organization's networked computing system.
Thus, many organizations invest a lot of efforts and costs in preventive means designed to protect their computing networks against potential threats. There are many defensive products offered in the market claiming to provide protection against one or more known modes of attack, and many organizations arm themselves to the teeth with multiple products of this kind.
However, it is difficult to tell how effective such products really are in achieving their stated goals of blocking hostile attacks, and consequently most CISOs (Computer Information Security Officers) will admit (maybe only off the record), that they don't really know how well they can withstand an attack from a given adversary. The only way to really know the strength and security of a system, is by trying to attack it as a real adversary would. This is known as red-teaming or penetration testing (pen testing, in short), and is a very common approach that is even required by regulation in some developed countries.
Penetration testing requires highly talented people to man the testing team. Those people should be familiar with each and every publicly known vulnerability and attacking method and should also have a very good familiarity with networking techniques and multiple operating systems implementations. Such people are hard to find and therefore many organizations give up establishing their own penetration testing teams and resort to hiring external expert consultants for carrying out that role (or completely give up penetration testing). However, external consultants are expensive and therefore are typically called in only for brief periods separated by long intervals in which no penetration testing is carried out. This makes the penetration testing ineffective, as vulnerabilities caused by new attacks, that appear almost daily, are discovered only months after becoming serious threats to the organization.
Additionally, even rich organizations that can afford hiring talented experts for in-house penetration testing teams do not achieve good protection. Testing for vulnerabilities of a large network containing many types of computers, operating systems, network routers and other devices is both a very complex and a very tedious process. The process is prone to human errors such as missing testing for certain threats or misinterpreting the damages of certain attacks. Additionally, because a process of full testing against all threats is quite long, the organization might again end with a too long discovery period after a new threat appears.
In view of the above difficulties, several vendors are proposing automated penetration testing systems. These automated solutions reduce human involvement in the penetration testing process, or at least in some of its functions. Some such systems automatically discover and report vulnerabilities of a networked system, potential damages that might be caused to the networked system, and potential trajectories of attack that may be employed by an attacker.
A penetration testing process involves at least the following main functions: (i) a reconnaissance function, (ii) an attack function, and (ii) a reporting function. The process may also include additional functions, for example a cleanup function that restores the tested networked system to its original state as it was before the test. In an automated penetration testing system, at least one of the above three functions is at least partially automated, and typically two or three of them are at least partially automated.
A reconnaissance function is the function within a penetration testing system that handles the collection of data about the tested networked system. The collected data may include internal data of networks nodes, data about network traffic within the tested networked system, business intelligence data of the organization owning the tested networked system, etc. The functionality of a prior art reconnaissance function can be implemented, for example, by software executing in a server that is not one of the network nodes of the tested networked system, where the server probes the tested networked system for the purpose of collecting data about it.
An attack function is the function within a penetration testing system that handles the determination of whether security vulnerabilities exist in the tested networked system based on data collected by the reconnaissance function. The functionality of a prior art attack function can be implemented, for example, by software executing in a server that is not one of the nodes of the tested networked system, where the server attempts to attack the tested networked system for the purpose of verifying that it can be compromised.
A reporting function is the function within a penetration testing system that handles the reporting of results of the penetration testing system. The functionality of a prior art reporting function may be implemented, for example, by software executing in the same server that executes the functionality of the attack function, where the server reports the findings of the attack function to an administrator or a CISO of the tested networked system.
FIG. 1A (PRIOR ART) is a block diagram of code modules of a typical penetration testing system. FIG. 1B (PRIOR ART) is a related flow-chart.
In FIG. 1A, code for the reconnaissance function, for the attack function, and for the reporting function are respectively labelled as 20, 30 and 40, and are each schematically illustrated as part of a penetration testing system code module (PTSCM) labelled as 10. The term ‘code’ is intended broadly and may include any combination of computer-executable code and computer-readable data which when read affects the output of execution of the code. The computer-executable code may be provided as any combination of human-readable code (e.g. in a scripting language such as Python), machine language code, assembler code and byte code, or in any form known in the art. Furthermore, the executable code may include any stored data (e.g. structured data) such as configuration files, XML files, and data residing in any type of database (e.g. a relational database, an object-database, etc.).
In one example and as shown in FIG. 1B, the reconnaissance function (performed in step S21 by execution of reconnaissance function code 20), the attack function (performed in step S31 by execution of attack function code 30) and the reporting function (performed in step S41 by execution of reporting function code 40) are executed in strictly sequential order so that first the reconnaissance function is performed by executing code 20 thereof, then the attack function is performed by executing code 30 thereof, and finally the reporting function is performed 40 by executing code thereof.
However, the skilled artisan will appreciate that this order is just one example, and is not a requirement. For example, the attack and the reporting functions may be performed in parallel or in an interleaved way, with the reporting function reporting first results obtained by the attack function, while the attack function is working on additional results.
Similarly, the reconnaissance and the attack functions may operate in parallel or in an interleaved way, with the attack function detecting a vulnerability based on first data collected by the reconnaissance function, while the reconnaissance function is working on collecting additional data.
FIG. 1A also illustrates code of an optional cleanup function which is labeled as 50. Also illustrated in FIG. 1B is step S51 of performing a cleanup function—e.g. by cleanup function code 50 of FIG. 1A.
“A campaign of penetration testing” is a specific run of a specific test of a specific networked system by the penetration testing system.
A penetration-testing-campaign module may comprise at least part of reconnaissance function code 20, attack function code 30 and optionally cleanup function code 50—for example, in combination with suitable hardware (e.g. one or more computing device(s) 110 and one or more processor(s) 120 thereof, see FIG. 2) for executing the code.
FIG. 2 illustrates a prior art computing device 110 which may have any form-factor including but not limited to a laptop, a desktop, a mobile phone, a server, a tablet, or any other form factor. The computing device 110 in FIG. 2 includes (i) computer memory 160 which may store code 180; (ii) one or more processors 120 (e.g. central-processing-unit (CPU)) for executing code 180; (iii) one or more human-interface device(s) 140 (e.g. mouse, keyboard, touchscreen, gesture-detecting apparatus including a camera, etc.) or an interface (e.g. USB interface) to receive input from a human-interface device; (iv) a display device 130 (e.g. computer screen) or an interface (e.g. HDMI interface, USB interface) for exporting video to a display device and (v) a network interface 150 (e.g. a network card, or a wireless modem).
Memory 160 may include any combination of volatile (e.g. RAM) and non-volatile (e.g. ROM, flash, disk-drive) memory. Code 180 may include operating-system code—e.g. Windows®, Linux®, Android®, Mac-OS®.
Computing device 110 may include a user-interface for receiving input from a user (e.g. manual input, visual input, audio input, or input in any other form) and for visually displaying output. The user-interface (e.g. graphical user interface (GUI)) of computing device 110 may thus include the combination of HID device 140 or an interface thereof (i.e. in communication with an external HID device 140), display device 130 or an interface thereof (i.e. in communication with an external display device), and user-interface (UI) code stored in memory 160 and executed by one or more processor(s) 120. The user-interface may include one or more GUI widgets such as labels, buttons (e.g. radio buttons or check boxes), sliders, spinners, icons, windows, panels, text boxes, and the like.
In one example, a penetration testing system is the combination of (i) code 10 (e.g. including reconnaissance function code 20, attack function code 30, reporting function code 40, and optionally cleaning function code 50); and (ii) one or more computing devices 110 which execute the code 10. For example, a first computing device may execute a first portion of code 10 and a second computing device (e.g. in networked communication with the first computing device) may execute a second portion of code 10.
Penetration testing systems may employ different types of architectures, each having its advantages and disadvantages. Examples are actual attack penetration testing systems, simulated penetration testing systems and reconnaissance agent penetration testing systems. See the Definitions section for more details about these types of penetration testing systems.
The Problem to Solve
When a user desires to perform a penetration test to evaluate the vulnerabilities of a tested networked system using a prior art penetration testing system, the penetration testing system must know when it should halt, or terminate, the test. As some networked systems contain thousands of network nodes, a penetration test may take a very long time. Additionally, sometimes compromising of a specific node might depend on an occurrence of some specific circumstances (for example performing by the specific node of some specific action, such as sending out a WPAD network message in order to find out a configuration file that determines a proxy server for a target URL) that do not occur frequently, and this might further extend the duration of a penetration test. Therefore, it is not always desirable to let a penetration test run to its ultimate end, which is (i) compromising all the network nodes of the tested networked system, or (ii) giving up before compromising all the network nodes after concluding that no further progress is possible because no additional network node can be compromised.
Prior art penetration testing systems may give the user an option for halting the test according to a target-nodes-based halting condition. For example, the user may define a single specific target node in the tested networked system and then specify that the test should halt after that target node is compromised. Alternatively, the user may define multiple specific target nodes in the tested networked system and then specify that the test should halt after all the target nodes are compromised, or after any one of the target nodes is compromised.
Additionally, prior art penetration testing systems may give the user an option for halting the test according to a target-application-based halting condition. For example, the user may define a target application (e.g. a certain financial application used by the organization owning the tested networked system) and then specify that the test should halt after the target application is compromised in any node of the networked system.
Furthermore, prior art penetration testing systems may give the user an option for halting the test according to a time-based halting condition. For example, the user may specify that the test should halt after executing for a predetermined duration, such as six hours, or that the test should halt at a specific time, for example at 3 am.
Additionally, prior art penetration testing systems may apply an implied halting condition derived from the goal of the attacker of the penetration testing campaign. For example, if the goal of the attacker is to “compromise at least five network nodes” and the penetration testing system is configured to halt when reaching the goal, then the penetration testing system acts as if there is a halting condition of “at least five network nodes are already compromised” in effect.
All the above halting conditions may collectively be called “direct halting conditions”, as they all provide a direct and simply-defined condition for halting the penetration test. In the present application, all other types of halting conditions are termed “indirect halting conditions”, as defined in the Definitions section hereinbelow.
The flexibility provided by the direct halting conditions discussed above is limited. For example, a user running a penetration test may desire to halt the test once a specific defensive application is detected to exist in the tested networked system. As another example, the user may desire to stop the test once a certain number of files of a certain type (for example Excel files) are successfully exported (or it is determined that it would be possible for a potential attacker to export them) outside the networked system. The direct halting conditions proposed by prior art penetration testing systems are not good enough for supporting such user needs.
There is therefore a need in the art for an automatic penetration testing system and a method allowing a user to define or select any desired termination condition or halting condition.